kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19941031-19941221/[e-mail]_Tue Nov 8 17:00:25 1994.msg

Internet Message Format | 1995-07-31 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12617
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Wed, 9 Nov 1994 07:56:57 -0500
Received: by apakabar.cc.columbia.edu id AA09992
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 9 Nov 1994 07:56:56 -0500
Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: C-Kermit vs MS-Kermit
Message-Id: <[e-mail]>
Date: 8 Nov 94 23:00:25 MDT
References: <Pine.SUN.3.90.941106143639.22421D-100000@blue> <39mf2a$[e-mail]> <[e-mail]> <39omj0$[e-mail]>
Organization: Utah State University
Lines: 50
Apparently-To: [e-mail]

In article <39omj0$[e-mail]>, [e-mail] (Ken Pizzini) writes:
> (Sorry for continuing this thread in cpkm...)
>
> In article <[e-mail]>,
> Jeffrey Hurwit <[e-mail]> wrote:
>>In article <39mf2a$[e-mail]>,
>>Frank da Cruz ([e-mail]) wrote:
>>
>>>Although it might be unfashionable these days, there still is quite
>>>a lot to be said for assembly language, especially when memory and
>>>addressability are at a premium.
>>
>>    Oh, I wouldn't say that (unfashionable, that is).  Shareware
>>    authors often advertise the fact if they wrote their programs in
>>    assembly, and sometimes go on to point out the advantages:  A
>>    program that's small and fast.  There's no compiler in the world
>>    that can optimize like a knowledgeable programmer.  IMHO, well-
>>    written assembly is definitely a feature that savvy users look for.
>
> The problem with assembly is that complicated-but-faster algorithms
> are less likely to be used, and it is much more likely that arbritrary
> limits on data sizes will be introduced in order to simplify programming.
> Also modern compilers will do a better job of optimizing than a
> mediocre programmer, in most cases.  In the optimize-for-speed relm it
> is much more fruitful to program in a high-level-language, profile the
> resulting program, and hand-code only the routines thus determined to
> be critical.
>
> Then again, modern compilers are usually built to optimize for speed,
> not space.  If memory is tight hand-coded assembly still has an edge.
> If nothing else it will encourage the programmer to leave out some
> unnecessary bells and whistles.
------------
    May I end this thread as a person with some experience in both
assembler and C?
    There is no way C can beat decent assembler. All those push/pops
and stack references (that's touching real memory folks) kill performance.
Programs beyond the hobbyist level aren't designed and written by undoing
C code to assembler; far from it. They are designed differently from the
ground up.
    I doubt many readers here have any idea of what is involved using
C without all the helpful crutches provided by the compiler vendor. Remove
the startup routines, and the run time libraries, and mix in near and far
code and data, add interrupt routines. That will do for openers. It's not
at all like programming "Hello World\n". Yet this occurs in MS-DOS Kermit
which is 80% assembler and which uses C for the TCP/IP stack, and that's
run partly at interrupt level and never as a "main" program. There is
no main() nor any vendor libraries etc. And I wish your last phrase were
true, sigh.
    Joe D.